\subsection{Risks and name resolution attacks}
\label{sec:risks}

Secure systems are not monolithic.  They depend on a heterogeneous collection of hardware and an unavoidably large base of software and data.  No program runs in isolation, and the fidelity of even the most robust application can be challenged if it is run in an environment where anything and everything in its environment can be controlled by an adversary.  Therefore, security of one system is inseparable from trust of the underlying platform.  To be meaningful, trust must be based on some attestable qualities of an object, such as being accessed across a trusted channel, or coming from a trusted origin.  Unfortunately, the issues of attesting to the trustworthiness of an object can be complex, as the act merely of resolving a name to a resource can be perilous.

\begin{figure}
\centering
\includegraphics[width=3in]{Images/link_tree.png}
\caption{A directory tree including a symbolic link that might complicate name resolution}
\label{fig:link_tree}
\end{figure}

One of the common active areas of both practical attacks and security research is name resolution attacks \cite{conf/ndss/ChariHV10,ec2nd11-vijayakumar,Cai:2009:EUF:1607723.1608123}.  In a name resolution attack, an adversary interferes in the process of resolving a file name to an actual resource.  These attacks come in two forms.  In the first form, an improper binding attack, the adversary creates links (either symbolic or hard) somewhere in the chain of directories that must be followed to find a file.

A directory tree with a symbolic link in red is shown in Figure \ref{fig:link_tree}.  In this case, a process, possibly a confused deputy \cite{Hardy:1988:CD:54289.871709}, can be tricked into thinking it is modifying an unimportant file located at $/A/C/D$ when in reality this path resolves to a protected resource at $/A/B/D$ - a higher-integrity file existing elsewhere in the file system, e.g. from $/home/me/text$ to $/etc/passwd$.  The actual resource at this location might be something the deputy would never intentionally access, like a configuration for a web server or a password file.  Conversely, a program might expect to find its configuration file at $/A/C/D$ only to follow a modified path to $/A/B/D$.

In an improper resource attack, the attacker forges a malicious file and leads the victim to use it.  Thus, a process may be controlled by an adversary through the operation specified in a malicious file, e.g. an executable binary or configuration.  An adversary-controlled configuration file could drastically affect the behaviors of a privileged program and allow an entire system to be compromised.  

To prevent such link shenanigans, a path must be canonicalized.  This is simply the process of resolving the path directly to the root, without any symbolic links.  This is done in reverse: given a resource, work backwards across hard links until the root is found.  Unfortunately, checking that a name resolution maps to a resource and canonicalizing a path are a prime targets for race conditions.

\begin{figure}
\centering
\includegraphics[width=2in]{Images/TOCTTOU.png}
\caption{Example of a time-of-check-to-time-of-use attack, showing one possible opportunity for name binding manipulation}
\label{fig:TOCTTOU}
\end{figure}

Unfortunately, name resolution attacks are difficult to prevent, especially from the user level.  Take the case of a time-to-check to time-of-use (TOCTTOU) attack.  In this type of attack, an adversary changes a name binding between the moment the integrity of a file is checked and the moment when the file is actually used.  The major drawback of common solutions lies in the dependence on application programming:  every user-space program must roll its own security and check for suspicious files.  Naturally, the results across diverse programs are uneven and full of security holes.

In the case of TOCTTOU, or any attack based on a race condition, it is impossible for a user-space process to guarantee its own security.  The reason is that the system calls to check a file and the system calls to open a file are separate and therefore not atomic.  This is shown in Figure \ref{fig:TOCTTOU}. Because the operating system controls scheduling, a user-space program cannot guarantee its own name bindings.  Although a longshot, a determined attacker will eventually find the gap if given enough chances.


